Java standards for web services are constantly being developed. Concurrently, businesses are building important applications on top of web services infrastructures, such as that available in WebLogic Server from BEA Systems of San Jose, Calif. As these applications evolve, they become more complex with more operations to perform. In many implementations, a server may perform transactions involving multiple resources. Transactional guarantees when making updates to the resources are important and should be performed as quickly as possible.
The WebLogic Server (WLS) Transaction Manager (TM) provides a full-featured two-phase commit transaction engine that implements the Java Transaction API (JTA) specification. Java 2 Enterprise Edition (J2EE) applications deployed on WLS make use of the TM and the JTA interfaces to effect atomic, persistent changes to data that are managed by one or more transactional resources. Transactional resources, such as RDBMS and messaging systems, support the XAResource interface as defined by the JTA specification. A representative server-resource system 100 is illustrated in FIG. 1. In FIG. 1, an environment for a server computer 110 includes server 120, a first resource 130, and second resource 140. Server 120 includes transaction manager 150. Resources are accessed by an application to perform updates to persistent data. The transaction manager is used to ensure that the updates happen atomically with transactional guaranties. This process is described in more detail in “Open Group Distributed Transactions Processing” by Java Inc, incorporated by reference herein.
WLS internally manages several thread pools that are used to process application logic, administrative requests, inter-server communication and other operations specific to server management. The TM utilizes server threads to perform various transaction-related operations on behalf of the application such as coordinating transactions across multiple servers, transaction timeout processing, transaction recovery processing, and other operations. System 200 of FIG. 2 illustrates a server thread of the prior art. As shown, a server 120 includes a thread 210. Previously, accessing transactional resources from within a WLS global transaction would cause the TM to perform all resource interactions from within the thread assigned to the application component. Thus, as shown in FIG. 2, the thread 210 includes all interactions such as access resources R1 and R2, two-phase commit processing which includes preparing resources R1 and R2 and committing resources R1 and R2. The two transactional resources are registered and accessible to applications.
There are several XA interactions that take place between the TM and a resource during the course of a transaction as prescribed by the JTA specification. With reference to FIGS. 1 and 2, an application may begin a transaction and update resources 130 and 140 on server 120. The application logic is dispatched to a server thread 210 running in server 120. The application thread then starts a transaction, updates resources, and commits the transaction. Within the thread 210, the application updates data in first resource 130 and then a second resource 140.
A method 300 of the prior art for performing a transaction according to the JTA specification is illustrated in FIG. 3. Method 300 begins with start step 305. Next, resources are enlisted at step 310. Resource enlistment occurs when a resource is accessed within the scope of a transaction and it associates the application's changes with a transaction that is under the control of the TM. Thus, when the application commits the transaction, control of the application thread is given to the TM 150. Next, the participating resources are signaled to prepare to commit in step 320. The TM 150 then sequentially prepares each resource. Each resource is asked by the TM whether the application changes made under the transaction can be made permanent. The TM then determines if all resources are able to commit at step 330. Once all resources have responded to the prepare directive, the transaction manager will either commit or abort the transaction and inform the resource participants of the outcome. If the resources do not all respond positively to the prepare request, then operation continues to step 350 where the TM aborts the transaction. The application may alternatively issue an abort request for the transaction and the TM will only invoke the rollback operation on the resources. If all resources commit at step 330, the TM issues a commit operation signal and the transaction proceeds at step 340. After the TM signals for either a commit or an abort, operation ends at step 365. The prepare, rollback and commit operations are issued in sequence to each locally-accessible resource that is enlisted in the transaction on any given server that is participating in the transaction. If there are additional servers and resources participating in the transaction then each server would invoke the XA operations serially for those participating resources that are locally accessible.
Performing resource prepare, commit and rollback operations serially as currently done in the prior art can be inefficient since these XA operations may require long processing times. What is needed is a system and method for processing transactions that overcomes the limitations and disadvantages of the prior art.